Skip to content

Conversation

@danobi
Copy link
Owner

@danobi danobi commented Nov 17, 2023

XXX should fail

Checklist
  • Language changes are updated in man/adoc/bpftrace.adoc and if needed in docs/reference_guide.md
  • User-visible and non-trivial changes updated in CHANGELOG.md
  • The new behaviour is covered by tests

danobi pushed a commit that referenced this pull request Jul 18, 2024
If it is dummy, then the visit() operation should not be executed. For
example, on aarch64, there is no syscalls:sys_{enter,exit}_open
tracepoint, however, opensnoop.bt tool will try to attch them and visit
args's field. We expect to get a warning, but instead we get a segmentation
fault. As follows:

    $ sudo gdb bpftrace
    ...
    (gdb) set args opensnoop.bt
    (gdb) r
    opensnoop.bt:22-24: WARNING: tracepoint not found: syscalls:sys_enter_open
    opensnoop.bt:28-30: WARNING: tracepoint not found: syscalls:sys_exit_open

    Thread 1 "bpftrace" received signal SIGSEGV, Segmentation fault.
    0x000000000052bbd8 in __gnu_cxx::__normal_iterator<bpftrace::Field const*, std::vector<bpftrace::Field, std::allocator<bpftrace::Field> > >::__normal_iterator (this=0xffffffffb0b8, __i=<error reading variable: Cannot access memory at address 0x10>)
        at /usr/include/c++/14/bits/stl_iterator.h:1068
    1068              : _M_current(__i) { }
    (gdb) bt
    #0  0x000000000052bbd8 in __gnu_cxx::__normal_iterator<bpftrace::Field const*, std::vector<bpftrace::Field, std::allocator<bpftrace::Field> > >::__normal_iterator (this=0xffffffffb0b8,
        __i=<error reading variable: Cannot access memory at address 0x10>) at /usr/include/c++/14/bits/stl_iterator.h:1068
    #1  0x0000000000525bdc in std::vector<bpftrace::Field, std::allocator<bpftrace::Field> >::begin (this=0x10)
        at /usr/include/c++/14/bits/stl_vector.h:884
    bpftrace#2  0x000000000059ce8c in bpftrace::Struct::GetField (this=0x0, name="filename")
        at /home/rongtao/Git/bpftrace/bpftrace/src/struct.cpp:131
    bpftrace#3  0x00000000005a70a0 in bpftrace::SizedType::GetField (this=0xe9b998, name="filename")
        at /home/rongtao/Git/bpftrace/bpftrace/src/types.cpp:538
    bpftrace#4  0x00000000007c7178 in bpftrace::ast::CodegenLLVM::visit (this=0xffffffffc650, acc=...)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/passes/codegen_llvm.cpp:1973
    bpftrace#5  0x0000000000847db0 in bpftrace::ast::FieldAccess::accept (this=0xe9be30, v=...)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/ast.cpp:31
    bpftrace#6  0x00000000007d2404 in bpftrace::ast::CodegenLLVM::accept (this=0xffffffffc650, node=0xe9be30)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/passes/codegen_llvm.cpp:3778
    bpftrace#7  0x00000000007c8bec in bpftrace::ast::CodegenLLVM::visit (this=0xffffffffc650, assignment=...)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/passes/codegen_llvm.cpp:2218
    bpftrace#8  0x0000000000847eb4 in bpftrace::ast::AssignMapStatement::accept (this=0xffffe4429250, v=...)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/ast.cpp:36
    bpftrace#9  0x00000000007d2404 in bpftrace::ast::CodegenLLVM::accept (this=0xffffffffc650, node=0xffffe4429250)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/passes/codegen_llvm.cpp:3778
    bpftrace#10 0x00000000007ca4c4 in bpftrace::ast::CodegenLLVM::generateProbe (this=0xffffffffc650, probe=..., full_func_id="dummy",
        name="dummy", func_type=0xff2b50, usdt_location_index=std::optional [no contained value], dummy=true)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/passes/codegen_llvm.cpp:2539
    bpftrace#11 0x00000000007cb4e4 in bpftrace::ast::CodegenLLVM::visit (this=0xffffffffc650, probe=...)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/passes/codegen_llvm.cpp:2734
    bpftrace#12 0x00000000008480f0 in bpftrace::ast::Probe::accept (this=0xffffe4427650, v=...)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/ast.cpp:47
    bpftrace#13 0x00000000007d2404 in bpftrace::ast::CodegenLLVM::accept (this=0xffffffffc650, node=0xffffe4427650)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/passes/codegen_llvm.cpp:3778
    bpftrace#14 0x00000000007cb7a4 in bpftrace::ast::CodegenLLVM::visit (this=0xffffffffc650, program=...)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/passes/codegen_llvm.cpp:2752
    bpftrace#15 0x000000000084818c in bpftrace::ast::Program::accept (this=0xe90f50, v=...)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/ast.cpp:50
    bpftrace#16 0x00000000007d2404 in bpftrace::ast::CodegenLLVM::accept (this=0xffffffffc650, node=0xe90f50)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/passes/codegen_llvm.cpp:3778
    bpftrace#17 0x00000000007d03fc in bpftrace::ast::CodegenLLVM::generate_ir (this=0xffffffffc650)
        at /home/rongtao/Git/bpftrace/bpftrace/src/ast/passes/codegen_llvm.cpp:3450
    bpftrace#18 0x0000000000478138 in main (argc=2, argv=0xfffffffff4c8) at /home/rongtao/Git/bpftrace/bpftrace/src/main.cpp:898

We can simplify opensnoop.bt to:

    tracepoint:syscalls:sys_enter_open_not_exist,
    tracepoint:syscalls:sys_enter_openat
    {
        @ = args.filename;
    }

This will produce the following error:

    stdin:1:1-45: WARNING: tracepoint not found: syscalls:sys_enter_open_not_exist
    tracepoint:syscalls:sys_enter_open_not_exist,tracepoint:syscalls:sys_enter_openat {@ = args.filename;}
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Segmentation fault

We need to generate the dummy probe only for cases when none of the probe
attach points exists.

Link: bpftrace#3274
Signed-off-by: Viktor Malik <viktor.malik@gmail.com>
Signed-off-by: Rong Tao <rongtao@cestc.cn>
danobi added a commit that referenced this pull request Jan 30, 2025
Seems like 1 clock cycle is too much for the kernel to handle - we get
softlockups:

```
[ RUN      ] probe.probe_builtin_scratch_buf
[  788.058977] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:0]
[  788.061316] Modules linked in: xfs nf_tables nfnetlink kvm
[  788.063176] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0 #1
[  788.065341] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[  788.069123] RIP: 0010:handle_softirqs+0x7a/0x2c0
[  788.070694] Code: 00 01 00 00 bd 0a 00 00 00 44 89 64 24 14 45 89 f7 89 6c 24 10 40 88 7c 24 04 31 c0 65 66 89 05 74 a5 f9 46 fb bb ff ff ff ff <48> c7 c0 c0 60 40 ba 41 0f bc df 83 c3 01 49 89 c2 74 75 8d 43 ff
[  788.076737] RSP: 0018:ffff93e700003f98 EFLAGS: 00000246
[  788.078449] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0
[  788.080828] RDX: 00000000000001b3 RSI: ffffffffba40a940 RDI: 0000000000000000
[  788.083187] RBP: 000000000000000a R08: 000000b1cd070240 R09: 7fffffffffffffff
[  788.085542] R10: 000000b1ccf7c000 R11: 0000000000005936 R12: 0000000004200002
[  788.087975] R13: 0000000000000000 R14: 0000000000000002 R15: 0000000000000002
[  788.090347] FS:  0000000000000000(0000) GS:ffff9183bbc00000(0000) knlGS:0000000000000000
[  788.093023] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  788.094954] CR2: 00007fa0843f7b8c CR3: 000000010029e003 CR4: 0000000000370ef0
```

My uneducated guess is the high frequency is triggering some kind of
race condition that's exacerbated by slow nested-virtualization VMs.

I reported this to Song but he could not reproduce the issue. So let's
just bump to 100,000 clock cycles to avoid bringing down CI.
danobi added a commit that referenced this pull request Feb 1, 2025
Seems like 1 clock cycle is too much for the kernel to handle - we get
softlockups:

```
[ RUN      ] probe.probe_builtin_scratch_buf
[  788.058977] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:0]
[  788.061316] Modules linked in: xfs nf_tables nfnetlink kvm
[  788.063176] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0 #1
[  788.065341] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[  788.069123] RIP: 0010:handle_softirqs+0x7a/0x2c0
[  788.070694] Code: 00 01 00 00 bd 0a 00 00 00 44 89 64 24 14 45 89 f7 89 6c 24 10 40 88 7c 24 04 31 c0 65 66 89 05 74 a5 f9 46 fb bb ff ff ff ff <48> c7 c0 c0 60 40 ba 41 0f bc df 83 c3 01 49 89 c2 74 75 8d 43 ff
[  788.076737] RSP: 0018:ffff93e700003f98 EFLAGS: 00000246
[  788.078449] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0
[  788.080828] RDX: 00000000000001b3 RSI: ffffffffba40a940 RDI: 0000000000000000
[  788.083187] RBP: 000000000000000a R08: 000000b1cd070240 R09: 7fffffffffffffff
[  788.085542] R10: 000000b1ccf7c000 R11: 0000000000005936 R12: 0000000004200002
[  788.087975] R13: 0000000000000000 R14: 0000000000000002 R15: 0000000000000002
[  788.090347] FS:  0000000000000000(0000) GS:ffff9183bbc00000(0000) knlGS:0000000000000000
[  788.093023] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  788.094954] CR2: 00007fa0843f7b8c CR3: 000000010029e003 CR4: 0000000000370ef0
```

My uneducated guess is the high frequency is triggering some kind of
race condition that's exacerbated by slow nested-virtualization VMs.

I reported this to Song but he could not reproduce the issue. So let's
just bump to 100,000 clock cycles to avoid bringing down CI.
danobi pushed a commit that referenced this pull request May 16, 2025
Standardized benchmarks are hard! Since we most often want to use
benchmarks in an ad-hoc fashion, can build it directly into the main
binary as a `--test` option (a new test mode).

The benchmark mechanism is implementation totally transparently to all
the internals, and operates exclusively on the `PassManager`. It
executes a benchmark for each pass. This shows a structured output with
every pass listed:

```
System
  OS: Linux 6.9.0-0_fbk3_1265_g43ac291a024d #1 SMP Wed Dec  4 07:06:17 PST 2024
  Arch: x86_64

Build
  version: v0.21.0-713-g4969-dirty
  LLVM: 18.1.8
  bfd: yes
  libdw (DWARF support): yes
  libsystemd (systemd notify support): no
  blazesym (advanced symbolization): yes

Kernel helpers
  probe_read: no                   probe_read_str: no
  probe_read_user: no              probe_read_user_str: no
  probe_read_kernel: no            probe_read_kernel_str: no
  get_current_cgroup_id: no        send_signal: no
  override_return: no              get_boot_ns: no
  dpath: no                        skboutput: no
  get_tai_ns: no                   get_func_ip: no
  jiffies64: no                    for_each_map_elem: no
  get_ns_current_pid_tgid: no      lookup_percpu_elem: no

Kernel features
  Instruction limit: -1            btf: yes
  module btf: no                   map batch: yes
  uprobe refcount: yes

Map types
  hash: yes                        array: yes
  percpu array: yes                stack_trace: no
  perf_event_array: yes            ringbuf: yes

Probe types
  kprobe: no                       tracepoint: no
  perf_event: no                   fentry: no
  kprobe_multi: no                 uprobe_multi: no
  kprobe_session: no               iter: no

ast                           10000   7205047       720 ± 582 ns
bpftrace                      10000   7724379       772 ± 576 ns
parse                         2103    100040389     47 ± 5 μs
ConfigAnalyser                3355    100029020     29 ± 3 μs
ResolveImports                1478    100015641     67 ± 9 μs
ImportScripts                 10000   15044124      1504 ± 878 ns
UnstableFeature               10000   18684501      1868 ± 972 ns
MacroExpansion                10000   19686928      1968 ± 910 ns
Deprecated                    10000   14804521      1480 ± 921 ns
attachpoints                  10000   52022211      5202 ± 1792 ns
btf                           10000   31688754      3168 ± 178502 ns
tracepoint                    10000   23252392      2325 ± 871 ns
FieldAnalyser                 10000   30305116      3030 ± 1106 ns
ClangParser                   4       105528964     26 ± 3 ms
CMacroExpansion               10000   17427514      1742 ± 815 ns
MapSugar                      10000   36848365      3684 ± 1439 ns
FoldLiterals                  10000   19861081      1986 ± 833 ns
PidFilter                     10000   16219805      1621 ± 911 ns
Semantic                      10000   37571204      3757 ± 2062 ns
ResourceAnalyser              10000   56294908      5629 ± 1611 ns
RecursionCheck                10000   21742022      2174 ± 1016 ns
ReturnPath                    10000   10208386      1020 ± 581 ns
Probe                         10000   24246794      2424 ± 1238 ns
llvm-init                     10000   58527480      5852 ± 2056 ns
compile                       1974    100048050     50 ± 30 μs
optimize                      567     100030093     176 ± 58 μs
object                        115     100232684     871 ± 167 μs
extern                        10000   14664920      1466 ± 806 ns
link                          4511    100005119     22 ± 7 μs
total                         29      803344776     27 ± 3 ms
PASS
```

Additional docs have been added for how to use this functionality, with
appropriate caveats.

Signed-off-by: Adin Scannell <amscanne@meta.com>

stack-info: PR: bpftrace#3998, branch: user/amscanne/map_pipelines2/3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants